The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Networks have become an important tool for businesses and consumers alike, many of which are now dependent on the constant availability of network resources such as mail servers, Web sites, and content servers. As use of networks increases, protecting networks from disruption by malicious entities becomes more important. For example, denial of service (“DoS”) attacks may deprive legitimate users of access to network services, and have been used successfully to disrupt legitimate user access to internet sites such as Yahoo! and CNN.
Data injection attacks may result in DoS or other adverse effects. One type of data injection attack takes advantage of the basic design of the Transmission Control Protocol (“TCP”), one of the foundational protocols of the Internet, as defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 793. In a data injection attack, an attacker guesses parameter values for a valid TCP connection and then sends spurious segments that contain malicious or spurious data payloads. If the receiver passes such segments to an application, malfunctions may occur when the application acts on or executes the data payloads.
A typical implementation of TCP that is compliant with RFC 793 and is acting as a receiver of data maintains out-of-order data in a re-assembly buffer pending receipt of any missing segments. The receiver sends an acknowledgment (“ACK”) message for each segment that is received out of order and indicating the last valid sequence number. The sender holds non-acknowledged segments in a re-transmission buffer. This process enables a sender to rapidly re-transmit segments that have been lost in transmission, because such segments are not acknowledged.
One type of TCP data injection attack exploits the foregoing mechanisms in TCP implementations that are intended to manage segments that arrive out-of-order and need to be re-assembled into the proper order before they are passed to applications at logical layers above TCP. Border Gateway Protocol (BGP), Hypertext Transfer Protocol (HTTP), some voice protocols, Multi-Protocol Label Switching (MPLS), and other protocols use TCP connections and are targets for these attacks. The consequences can be severe. For example, when a BGP session of a router is disrupted by closing the associated TCP connection, the router will discard all BGP routes that it has created, essentially causing a failure of the BGP process. As a result, the BGP process must re-synchronize itself with peer routers in the network, and during the re-synchronization period the failed router cannot forward any traffic.
Further, data injection attacks may result in presenting malicious commands to an upstream process, needlessly filling the re-assembly buffer, faulty operation of other higher-layer applications, initiating “ACK wars,” etc. Accordingly, researchers in this field are interested in creating ways to thwart TCP data injection attacks, without fundamentally altering the operation of TCP as specified in RFC 793.
A successful attack must inject a TCP segment that carries proper values for source port, destination port; a range of values is allowed for sequence number and ACK number. The allowed ranges for these values are large, so that mounting a brute-force attack involving serially checking all possible values for each parameter would seem impossible. However, in most TCP implementations the task of selecting valid values is simpler because certain loopholes present in RFC 793. These loopholes create security vulnerabilities in implementations that are compliant with RFC 793. For example, assigning a pseudo-random 32-bit value as the Initial Sequence Number (ISN) for a new TCP connection might appear to prevent an attacker from guessing the correct sequence number in any practical way, because the number of potentially correct values is 232 or approximately 4 billion values. However, a conventional TCP implementation compliant with RFC 793 will accept a segment if the sequence number of the segment falls within a window or range of acceptable values, even if the sequence number is not an exact match to the next expected sequence number. The window or range typically is the same as the size in bytes of the re-assembly buffer, and is used to compensate for the possibility that segments may be lost. In some implementations of TCP the range of allowed sequence values may be as large as 16,384,65,535, or larger.
A consequence is that the attacker does not need to generate all 32 bits of the sequence number correctly to provide a number that a receiving node will accept, even when a truly random or pseudorandom ISN is used. If the range of allowed sequence values is sufficiently large, then the chance is greatly increased that an attacker can guess a correct sequence value through either random or brute-force selection in a practical amount of time. The larger the window established by the receiving node, the easier it is for the hacker to carry out this attack.
Further, most implementations use a relatively small range of values for the initial port number, and merely increment the port number for each new connection. As a result, using ordinary computing resources it may be relatively easy for an attacker to guess the port values that are used by two endpoints to a legitimate TCP connection.
Still another vulnerability occurs because most TCP implementations do not test whether the ACK value is equal to an expected ACK value or even within a range of allowed ACK values. Instead, most implementations will accept any segment that carries an ACK value greater than a previously received ACK value, provided the sequence number is within the allowed range. RFC 793 defines an ACK value as an unsigned integer in the range 1 to 232. Thus, an attacker who guesses an allowed sequence number can succeed with a data injection attack by trying only two ACK values—one (1) or 232-1—and one or the other is certain to be accepted.
The result of the foregoing compromises is that an attacker can theoretically inject data into a connection in (232/window-size/2) segments, or roughly 30,000 segments in most implementations. Therefore even a brute-force attack can proceed relatively rapidly using conventional computing equipment.
Approaches for preventing network DoS Reset attacks are described in co-pending application Ser. No. 10/755,146, filed Jan. 9, 2004, entitled “Preventing Network Reset Denial of Service Attacks,” by Mitesh Dalal et al., Attorney Docket No. 50325-0868. An approach for addressing a similar attack, known as the SYN-RST attack, is provided in co-pending application Ser. No. 10/641,494, filed Aug. 14, 2003, entitled “Detecting network denial of service attacks,” of Pritam Shah et al., and assigned to the same assignee hereof. The approach of Shah et al. is appropriate for an intermediate router rather than a TCP endpoint device, but does not fully address all issues described in this disclosure.